Add naive csharp project support for vsxmake #4510
Conversation
|
|
||
| language("csharp") | ||
| add_rules("csharp") | ||
| set_sourcekinds {cs = {".cs"}} |
There was a problem hiding this comment.
add set_sourceflags {cs = {"csflags"}}
| -- $(MSBuildToolsPath)\Microsoft.CSharp.targets | ||
| -- $(XmakeProgramDir)\scripts\vsxmake\vsproj\Xmake.CSharp.targets | ||
| on_build(function(target) | ||
|
|
There was a problem hiding this comment.
vsxmake project should call xmake to build csharp.
|
I tried it and it worked, but it didn't call the xmake command to compile the cs project, but directly call vs to build it. If so, you should implement it in vs project generator (xmake project -k vs) instead of vsxmake. The vsxmake generator is only used to wrap xmake cli. The xmake command is directly called in the vs project to compile the csharp program. |
Thanks for the reply. I am aware of the fact that it not completely fits in the vsxmake build paradigm. I am trying to figure out a
|
|
I think it's worth a shot to implement it in for the vs project generator first since it's not going away (vsxmake generator doesn't fully replace it) and it would be great to have C# support in both native vs project and vsxmake/xmake backend. |
right, we can make vs generator to support csharp first. |
Kethers
force-pushed
the
C#VSProjSupport
branch
from
285232d to
6e17c82
Compare
|
I think if you want to use xmake as a build system for C#, you should start with csc (compilation tool), if you simply generate MSbuild project from xmake.lua, then this process may not make much sense, because MSbuild is simple and clear enough (at least in my opinion). |
Thanks for the advice. I know csc.exe. If you check the output log (set detail mode to at least normal) of c# project in vs you will see that it's calling csc.exe with source files plus some compilation options. My initial purpose was to make c# scripting orchestra with xmake and vs2022/rider so I just stopped when msbuild parse .csproj correctly. I haven't go that deep into xmake's compiler backend to see how it works. Furthermore c# ecosystem also have .Net core which might use ''dotnet build'' command. That should be taken into consideration becsuse it's more cross-platform than the old framework one (expired and no more update/newer version), especially when it comes to integrating to a cross-platform build system. Unfortunately at present I am busy doing other stuff and don't have not enough time for this pr. I will accomplish it in the future but I can't make time promise. |
|
Hello, are there any updates on this PR? |
No updates yet. Too busy to spend time on this. It's been almost a year and xmake has updated serveral versions. This PR needs more work and considerations to deploy. I will try to make some updates in next year. |
Note
This is a very naive and basic support for C# only in windows, and much much far from completely supports C# ecosystem like .Net Core or more advanced topics.
Motivation
I'm learning TheCherno's Game Engine Series courses. In the video Cherno uses premake as build tool. I decide to use xmake since it's getting popular in Chinese game & graphics development community. Everything works fine until the course step into C# Scripting and xmake hasn't supported csharp yet #1539. So I have to modified the xmake to make it work.
How it works in short
When building vsxmake solution, xmake generates .sln and .vcxproj files that uses XML (via customized template). When builds the target project, it uses MSBuild to analyze the .vcxproj. In the .vcxproj template it imports the
Xmake.targetsand the latter one use<Target>semantic to override the real build actions like config, build, clean, etc.To support CSharp project, here’s the work that needed:
For step 1, currently
set_languages(csharp)andadd_files("xx.cs")works fine, andset_kindonly supports binary and shared.For step 2 and 3, currently MSBuild.exe can parse the .sln and .csproj correctly. IntelliSense and Property setting window works fine (tested on VS2022 and Rider 2023.3.1).
For step 4, currently I use the
Microsoft.CSharp.targetsinstead ofXmake.CSharp.targetsto build targets, which means it doesn’t override the default build actions. Thus the build actions in therules/csharp/xmake.luawill not be executed at all.Optimizations & bug fixes
#target#.vcxprojis commented since initial commit. I don’t see why since uncomment it also works fine. For .vcxproj it’s just a slight improvement when using IDE. However for .csproj, it’s a necessary semantic otherwise IntelliSense disfunctions when referencing another C# project viaadd_deps(...).set_objectdir("...")doesn’t work correctly on .vcxproj because of hard-coded path, now it works fine.Maybe these changes can be extracted as another new pull request.
Test
CSharpTest.zip
Future work
Due to the limitation of time and my ability, there are many things that to be working on, and needs community collaborations:
When writing
#target#.csproj,Xmake.Common.propsandXmake.Csharp.targets(this file is not deployed), I take C++ project template files for reference. Thus in these files many C++ settings are left. I didn’t delete them for the reason of compatibility (lol, too noob to fully understood the xmake c++ build pipeline and relevant api mechanics). These legacy code should be cleaned up.For the similar reason, files in
languages/csharp/andrules/csharpalso contain a lot legacy code that copy from c++ corresponding files that should be cleaned up.Backend compilation override, and cross-platform, more C# ecosystem support and more apis for C# builds.
External reference